프런트엔드 콘텐츠 보안 정책(CSP) 논스 생성: 동적 스크립트 보안 강화

오늘날의 웹 개발 환경에서 프런트엔드 보안은 무엇보다 중요합니다. 사이트 간 스크립팅(XSS) 공격은 여전히 중대한 위협이며, 강력한 콘텐츠 보안 정책(CSP)은 필수적인 방어 메커니즘입니다. 이 글에서는 동적으로 주입되는 스크립트의 문제점과 해결책에 초점을 맞춰, 논스 기반 스크립트 허용 목록을 사용하여 CSP를 구현하는 종합적인 가이드를 제공합니다.

콘텐츠 보안 정책(CSP)이란 무엇인가?

CSP는 사용자 에이전트가 특정 페이지에 대해 로드할 수 있는 리소스를 제어할 수 있게 해주는 HTTP 응답 헤더입니다. 이는 본질적으로 브라우저에 어떤 소스가 신뢰할 수 있고 어떤 소스가 신뢰할 수 없는지 알려주는 허용 목록(whitelist)입니다. 이를 통해 공격자가 주입한 악성 스크립트를 브라우저가 실행하지 못하도록 제한하여 XSS 공격을 방지하는 데 도움이 됩니다.

CSP 지시문

CSP 지시문은 스크립트, 스타일, 이미지, 글꼴 등 다양한 유형의 리소스에 허용되는 소스를 정의합니다. 일반적인 지시문은 다음과 같습니다:

• `default-src`: 특정 지시문이 정의되지 않은 경우 모든 리소스 유형에 적용되는 폴백 지시문입니다.
• `script-src`: 자바스크립트 코드에 허용되는 소스를 지정합니다.
• `style-src`: CSS 스타일시트에 허용되는 소스를 지정합니다.
• `img-src`: 이미지에 허용되는 소스를 지정합니다.
• `connect-src`: 네트워크 요청(예: AJAX, WebSockets)에 허용되는 소스를 지정합니다.
• `font-src`: 글꼴에 허용되는 소스를 지정합니다.
• `object-src`: 플러그인(예: Flash)에 허용되는 소스를 지정합니다.
• `media-src`: 오디오 및 비디오에 허용되는 소스를 지정합니다.
• `frame-src`: 프레임 및 iframe에 허용되는 소스를 지정합니다.
• `base-uri`: `<base>` 요소에 사용할 수 있는 URL을 제한합니다.
• `form-action`: 폼을 제출할 수 있는 URL을 제한합니다.

논스(Nonce)의 힘

`script-src` 및 `style-src`를 사용하여 특정 도메인을 허용 목록에 추가하는 것도 효과적일 수 있지만, 제한적이고 유지 관리가 어려울 수 있습니다. 더 유연하고 안전한 접근 방식은 논스를 사용하는 것입니다. 논스(nonce, number used once)는 각 요청에 대해 생성되는 암호화된 난수입니다. CSP 헤더와 인라인 스크립트의 `<script>` 태그에 고유한 논스를 포함하면, 브라우저는 올바른 논스 값을 가진 스크립트만 실행하도록 지시할 수 있습니다.

논스를 사용한 CSP 헤더 예시:

Content-Security-Policy: default-src 'self'; script-src 'nonce-{{nonce}}'

논스를 사용한 인라인 스크립트 태그 예시:

<script nonce="{{nonce}}">console.log('Hello, world!');</script>

논스 생성: 핵심 개념

논스를 생성하고 적용하는 과정은 일반적으로 다음 단계를 따릅니다:

1. 서버 측 생성: 들어오는 각 요청에 대해 서버에서 암호학적으로 안전한 난수 논스 값을 생성합니다.
2. 헤더 삽입: 생성된 논스를 `Content-Security-Policy` 헤더에 포함시키고, `{{nonce}}`를 실제 값으로 대체합니다.
3. 스크립트 태그 삽입: 실행을 허용하려는 각 인라인 `<script>` 태그의 `nonce` 속성에 동일한 논스 값을 주입합니다.

동적으로 주입되는 스크립트의 문제점

논스는 정적 인라인 스크립트에는 효과적이지만, 동적으로 주입되는 스크립트는 문제를 야기합니다. 동적으로 주입되는 스크립트는 초기 페이지 로드 후, 종종 자바스크립트 코드에 의해 DOM에 추가되는 스크립트입니다. 초기 요청에 CSP 헤더를 설정하는 것만으로는 이렇게 동적으로 추가된 스크립트를 처리할 수 없습니다.

다음과 같은 시나리오를 생각해 보십시오: ```javascript function injectScript(url) { const script = document.createElement('script'); script.src = url; document.head.appendChild(script); } injectScript('https://example.com/script.js'); ``` 만약 `https://example.com/script.js`가 CSP에 명시적으로 허용되지 않았거나 올바른 논스를 가지고 있지 않다면, 초기 페이지 로드 시 유효한 CSP와 논스가 있었더라도 브라우저는 실행을 차단할 것입니다. 이는 브라우저가 리소스가 요청되거나 실행되는 시점에만 CSP를 평가하기 때문입니다.

동적으로 주입되는 스크립트를 위한 해결책

CSP와 논스를 사용하여 동적으로 주입되는 스크립트를 처리하는 몇 가지 접근 방식이 있습니다:

1. 서버 측 렌더링(SSR) 또는 사전 렌더링

가능하다면 스크립트 주입 로직을 서버 측 렌더링(SSR) 프로세스로 옮기거나 사전 렌더링 기술을 사용하십시오. 이를 통해 페이지가 클라이언트로 전송되기 전에 올바른 논스를 가진 필요한 `<script>` 태그를 생성할 수 있습니다. Next.js(React), Nuxt.js(Vue), SvelteKit과 같은 프레임워크는 서버 측 렌더링에 뛰어나며 이 과정을 단순화할 수 있습니다.

예시 (Next.js):

```javascript function MyComponent() { const nonce = getCspNonce(); // 논스를 가져오는 함수 return ( <script nonce={nonce} src="/path/to/script.js"></script> ); } export default MyComponent; ```

2. 프로그래밍 방식의 논스 주입

이 방법은 서버에서 논스를 생성하여 클라이언트 측 자바스크립트에서 사용할 수 있도록 한 다음, 동적으로 생성된 스크립트 요소에 `nonce` 속성을 프로그래밍 방식으로 설정하는 것을 포함합니다.

단계:

1. 논스 노출: 초기 HTML에 논스 값을 전역 변수나 요소의 데이터 속성으로 포함시킵니다. 쉽게 조작될 수 있으므로 문자열에 직접 포함하는 것은 피하십시오. 안전한 인코딩 메커니즘 사용을 고려하십시오.
2. 논스 검색: 자바스크립트 코드에서 저장된 위치로부터 논스 값을 검색합니다.
3. Nonce 속성 설정: 스크립트 요소를 DOM에 추가하기 전에 `nonce` 속성을 검색된 값으로 설정합니다.

예시:

서버 측 (예: Python/Flask에서 Jinja2 사용):

```html <div id="csp-nonce" data-nonce="{{ nonce }}"></div> ```

클라이언트 측 자바스크립트:

```javascript function injectScript(url) { const nonceElement = document.getElementById('csp-nonce'); const nonce = nonceElement ? nonceElement.dataset.nonce : null; if (!nonce) { console.error('CSP nonce not found!'); return; } const script = document.createElement('script'); script.src = url; script.nonce = nonce; document.head.appendChild(script); } injectScript('https://example.com/script.js'); ```

중요 고려사항:

• 안전한 저장: 논스를 노출하는 방법에 주의하십시오. HTML 소스의 자바스크립트 문자열에 직접 포함하는 것은 취약할 수 있으므로 피해야 합니다. 요소의 데이터 속성을 사용하는 것이 일반적으로 더 안전한 접근 방식입니다.
• 오류 처리: 구성 오류 등으로 인해 논스를 사용할 수 없는 경우를 정상적으로 처리하기 위해 오류 처리를 포함시키십시오. 스크립트 주입을 건너뛰거나 오류 메시지를 기록하도록 선택할 수 있습니다.

3. 'unsafe-inline' 사용 (권장하지 않음)

최적의 보안을 위해 권장되지는 않지만, `script-src` 및 `style-src` CSP 지시문에 `'unsafe-inline'` 지시문을 사용하면 인라인 스크립트와 스타일이 논스 없이 실행될 수 있습니다. 이는 사실상 논스가 제공하는 보호를 우회하고 CSP를 크게 약화시킵니다. 이 접근 방식은 최후의 수단으로만, 그리고 극도의 주의를 기울여 사용해야 합니다.

권장하지 않는 이유:

모든 인라인 스크립트를 허용함으로써 애플리케이션을 XSS 공격에 노출시키게 됩니다. 공격자는 페이지에 악성 스크립트를 주입할 수 있으며, CSP가 모든 인라인 스크립트를 허용하기 때문에 브라우저는 이를 실행할 것입니다.

4. 스크립트 해시

논스 대신 스크립트 해시를 사용할 수 있습니다. 이는 스크립트 내용의 SHA-256, SHA-384 또는 SHA-512 해시를 계산하고 `script-src` 지시문에 포함시키는 것을 포함합니다. 브라우저는 해시가 지정된 값과 일치하는 스크립트만 실행합니다.

예시:

`script.js`의 내용이 `console.log('Hello, world!');`이고, 그 SHA-256 해시가 `sha256-47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=`라고 가정하면, CSP 헤더는 다음과 같을 것입니다:

Content-Security-Policy: default-src 'self'; script-src 'sha256-47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='

장점:

• 정확한 제어: 해시가 일치하는 특정 스크립트만 실행하도록 허용합니다.
• 정적 스크립트에 적합: 스크립트 내용이 사전에 알려져 있고 자주 변경되지 않을 때 잘 작동합니다.

단점:

• 유지 관리 부담: 스크립트 내용이 변경될 때마다 해시를 다시 계산하고 CSP 헤더를 업데이트해야 합니다. 이는 동적 스크립트나 자주 업데이트되는 스크립트의 경우 번거로울 수 있습니다.
• 동적 스크립트에 대한 어려움: 동적 스크립트 내용을 즉석에서 해싱하는 것은 복잡할 수 있으며 성능 저하를 유발할 수 있습니다.

CSP 논스 생성을 위한 모범 사례

• 암호학적으로 안전한 난수 생성기 사용: 공격자가 논스를 예측할 수 없도록 논스 생성 과정에서 암호학적으로 안전한 난수 생성기를 사용해야 합니다.
• 각 요청마다 새로운 논스 생성: 다른 요청 간에 논스를 재사용해서는 안 됩니다. 각 페이지 로드마다 고유한 논스 값을 가져야 합니다.
• 안전한 논스 저장 및 전송: 논스가 가로채지거나 조작되지 않도록 보호하십시오. 서버와 클라이언트 간의 통신을 암호화하기 위해 HTTPS를 사용하십시오.
• 서버에서 논스 검증: (해당하는 경우) 스크립트 실행이 애플리케이션에서 비롯되었는지 확인해야 하는 시나리오(예: 분석 또는 추적)에서는 스크립트가 데이터를 다시 보낼 때 서버 측에서 논스를 검증할 수 있습니다.
• 정기적인 CSP 검토 및 업데이트: CSP는 '한 번 설정하고 잊어버리는' 해결책이 아닙니다. 새로운 위협과 애플리케이션의 변경 사항에 대처하기 위해 정기적으로 CSP를 검토하고 업데이트하십시오. 위반 사항을 모니터링하고 잠재적인 보안 문제를 식별하기 위해 CSP 보고 도구를 사용하는 것을 고려하십시오.
• CSP 보고 도구 사용: Report-URI나 Sentry와 같은 도구는 CSP 위반을 모니터링하고 CSP 구성의 잠재적인 문제를 식별하는 데 도움이 될 수 있습니다. 이러한 도구는 어떤 스크립트가 왜 차단되고 있는지에 대한 귀중한 통찰력을 제공하여 CSP를 개선하고 애플리케이션의 보안을 향상시킬 수 있도록 합니다.
• 보고 전용 정책으로 시작: CSP를 시행하기 전에 보고 전용 정책으로 시작하십시오. 이를 통해 실제로 리소스를 차단하지 않고 정책의 영향을 모니터링할 수 있습니다. 그런 다음 확신이 생기면 점차적으로 정책을 강화할 수 있습니다. `Content-Security-Policy-Report-Only` 헤더는 이 모드를 활성화합니다.

CSP 구현을 위한 글로벌 고려사항

전 세계 사용자를 대상으로 CSP를 구현할 때 다음 사항을 고려하십시오:

• 다국어 도메인 이름(IDN): CSP 정책이 IDN을 올바르게 처리하는지 확인하십시오. 브라우저는 IDN을 다르게 취급할 수 있으므로 예기치 않은 차단을 피하기 위해 다양한 IDN으로 CSP를 테스트하는 것이 중요합니다.
• 콘텐츠 전송 네트워크(CDN): CDN을 사용하여 스크립트와 스타일을 제공하는 경우 `script-src` 및 `style-src` 지시문에 CDN 도메인을 포함해야 합니다. 와일드카드 도메인(예: `*.cdn.example.com`)은 보안 위험을 초래할 수 있으므로 사용에 유의하십시오.
• 지역 규정: CSP 구현에 영향을 줄 수 있는 지역 규정을 숙지하십시오. 예를 들어, 일부 국가에서는 데이터 현지화 또는 개인 정보 보호에 대한 특정 요구 사항이 있을 수 있으며, 이는 CDN 또는 기타 타사 서비스 선택에 영향을 줄 수 있습니다.
• 번역 및 현지화: 애플리케이션이 여러 언어를 지원하는 경우 CSP 정책이 모든 언어와 호환되는지 확인하십시오. 예를 들어, 현지화를 위해 인라인 스크립트를 사용하는 경우 올바른 논스를 가지고 있거나 CSP에서 허용 목록에 포함되어 있는지 확인해야 합니다.

예시 시나리오: 다국어 이커머스 웹사이트

A/B 테스트, 사용자 추적 및 개인화를 위해 자바스크립트 코드를 동적으로 주입하는 다국어 이커머스 웹사이트를 생각해 보십시오.

과제:

• 동적 스크립트 주입: A/B 테스트 프레임워크는 종종 실험 변형을 제어하기 위해 스크립트를 동적으로 주입합니다.
• 타사 스크립트: 사용자 추적 및 개인화는 다른 도메인에서 호스팅되는 타사 스크립트에 의존할 수 있습니다.
• 언어별 로직: 일부 언어별 로직은 인라인 스크립트를 사용하여 구현될 수 있습니다.

해결책:

1. 논스 기반 CSP 구현: XSS 공격에 대한 주요 방어 수단으로 논스 기반 CSP를 사용합니다.
2. A/B 테스트 스크립트를 위한 프로그래밍 방식의 논스 주입: 위에서 설명한 프로그래밍 방식의 논스 주입 기술을 사용하여 동적으로 생성된 A/B 테스트 스크립트 요소에 논스를 주입합니다.
3. 특정 타사 도메인 허용 목록 추가: 신뢰할 수 있는 타사 스크립트의 도메인을 `script-src` 지시문에 신중하게 허용 목록에 추가합니다. 절대적으로 필요한 경우가 아니면 와일드카드 도메인 사용을 피합니다.
4. 언어별 로직을 위한 인라인 스크립트 해싱: 가능하다면 언어별 로직을 별도의 자바스크립트 파일로 옮기고 스크립트 해시를 사용하여 허용 목록에 추가합니다. 인라인 스크립트가 불가피한 경우, 스크립트 해시를 사용하여 개별적으로 허용 목록에 추가합니다.
5. CSP 보고: CSP 보고를 구현하여 위반 사항을 모니터링하고 예기치 않은 스크립트 차단을 식별합니다.

결론

CSP 논스로 동적으로 주입되는 스크립트를 보호하려면 신중하고 잘 계획된 접근 방식이 필요합니다. 단순히 도메인을 허용 목록에 추가하는 것보다 복잡할 수 있지만, 애플리케이션의 보안 상태를 크게 향상시킵니다. 이 글에서 설명한 문제점을 이해하고 해결책을 구현함으로써 프런트엔드를 XSS 공격으로부터 효과적으로 보호하고 전 세계 사용자를 위해 더 안전한 웹 애플리케이션을 구축할 수 있습니다. 항상 보안 모범 사례를 우선시하고 새로운 위협에 앞서 나가기 위해 정기적으로 CSP를 검토하고 업데이트하는 것을 잊지 마십시오.

이 가이드에 설명된 원칙과 기술을 따르면 동적으로 주입된 스크립트를 사용하면서도 웹사이트를 XSS 공격으로부터 보호하는 강력하고 효과적인 CSP를 만들 수 있습니다. CSP가 예상대로 작동하고 합법적인 리소스를 차단하지 않는지 확인하기 위해 철저하게 테스트하고 정기적으로 모니터링하는 것을 잊지 마십시오.